REMOTE NETWORK MANAGEMENT SYSTEM 



FIELD OF THE INVENTION 

The present invention relates generally to a remote 
5 network management system for remotely controlling network 
and computer equipment from one or more local user 
workstations through a remote control device. 
Specifically, a keyboard, video monitor, and cursor control 
device attached to a user workstation are utilized to 

10 remotely control domain servers, file/print servers, 

headless servers, network appliances, serial IT equipment, 
switches, routers, firewalls, security interfaces, 
application servers, load balancers, and environmental 
controls as their associated power supplies are connected 

15 to a remote control device. 

BACKGROUND OF THE INVENTION 

In many situations, it is desirable to manage 
networking equipment, servers, and computers located at a 
20 location remote from the system administrator. If the 

distance is great enough, the Internet is commonly utilized 
to control computers from a remote location. For example, 
a software program such as pcAnywhere may be utilized to 
access a remote computer over the Internet or a LAN 
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utilizing the keyboard, video monitor, and cursor control 
device attached to a local user workstation. Remote 
computer access programs, such as pcAnywhere, typically 
require that host software is installed on the remote 
5 computer and client software is installed on the user 

workstation. To access a remote computer, a user of the 
user workstation selects the desired remote computer from a 
list and enters the appropriate username and password. 
Once access has been granted to the remote computer, the 

10 user utilizes the keyboard, video monitor, and cursor 

control device attached to the local user workstation to 
access and operate the remote computer. 

Hardware solutions also exist for operating a remote 
computer from a user workstation over the Internet or via a 

15 modem. In contrast to software solutions, hardware 

solutions do not typically require host and/or client 
software. Instead, hardware solutions typically utilize a 
keyboard, video monitor, and mouse ("KVM") switch which is 
accessible over the Internet or LAN via a common protocol, 

20 such as TCP/IP. The hardware solutions may also utilize a 
modem to connect to the Internet. Generally, a user or 
system administrator accesses the remote computers attached 
to the KVM switch utilizing an Internet web-browser or 
client software associated with the KVM switch. Once the 
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remote computer has been selected, the remote computer's 
video signal is routed to the user workstation's video 
monitor and a user may then utilize a keyboard and/or mouse 
to control the remote computer. The KVM switch may 
5 additionally include a connection to the power source of 
the remote computer for a hard reboot in case of system 
failure . 

The aforementioned hardware and software solutions 
generally utilize compression algorithms to reduce the 

10 necessary bandwidth required to transmit the video signals. 
For example, the remote network management system of the 
present invention uses the compression algorithm disclosed 
in application serial no. 10/233,299, which is incorporated 
herein by reference, to reduce and compress the digital 

15 data that must be transmitted to the remote computers 

and/or video display devices. Generally, video signals 
generated by a personal computer have both spatial and 
interframe redundancies. For example, in a near idle 
personal computer, the only change between successive 

20 frames of video might be the blinking of a cursor. Even as 
a user types a document, a majority of the screen does not 
change over a period of time. Hence, the compression 
algorithm used by the present invention takes advantage of 
these redundancies, both between successive frames of video 



and within each individual frame, to reduce the amount of 
digital video signal data that is transmitted to the remote 
computers and/or video display devices. Reducing the 
amount of digital data transmitted over the communication 
medium decreases communication time and decreases the 
required bandwidth. 

Most forms of video compression known in the art 
require complicated calculations. For example, Moving 
Pictures Experts Group ("MPEG") video compression 
algorithms use the discrete cosine transform as part of its 
algorithm. Also, the MPEG standard relies on the 
recognition of "motion" between frames, which requires 
calculation of motion vectors that describe how portions of 
the video image have changed over a period of time. Since 
these algorithms are calculation intensive, they either 
require expensive hardware or extended transmission times 
that allow sufficient time for slower hardware to complete 
the calculations. 

In addition to complexity, many existing video 
compression techniques are lossy (i.e., they do not 
transmit all of the video signal information in order to 
reduce the required bandwidth) . Typically, such lossy 
techniques either reduce the detail of a video image or 
reduce the number of colors utilized. Although reducing 



the number of colors could be part of an adequate 
compression solution for some computer management systems 
applications, in many other applications, such a result 
defeats the intended purposes of the computer management 
5 system. 

The following references, which are discussed below, 
were found to relate to the field of computer management 
systems: Perholtz et al . U.S. Patent No. 5,732,212 
("Perholtz") , Beasley U.S. Patent No. 6,112,264 
10 ("Beasley"), Pinkston, II et al . U.S. Patent No. 6,378,009 
("Pinkston") , Thornton et al. U.S. Patent No. 6,385,666 
("Thornton"), and Wilder et al . U.S. Patent No. 6,557,170 
("Wilder") . 

Perholtz discloses a method and apparatus for coupling 
15 a local user workstation, including a keyboard, mouse, 
and/or video monitor, to a remote computer. Perholtz 
discloses a system wherein the remote computer is selected 
from a menu displayed on a standard size personal computer 
video monitor. Upon selection of a remote computer by the 
20 system user, the remote computer's video signals are 

transmitted to the local user workstation's video monitor. 
The system user may also control the remote computer 
utilizing the local user workstation's keyboard and 
monitor. The Perholtz system is also capable of bi- 
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directionally transmitting mouse and keyboard signals 
between the local user workstation and the remote computer. 
The remote computer and the local user workstation may be 
connected either via the Public Switched Telephone System 
5 ("PSTN") and modems or via direct cabling. 

Similar to Perholtz, Beasley discloses a specific 
implementation of a computerized switching system for 
coupling a local keyboard, mouse and/or video monitor to 
one of a plurality of remote computers. In particular, a 

10 first signal conditioning unit includes an on-screen 
programming circuit that displays a list of connected 
remote computers on the local video monitor. To activate 
the menu, a user depresses, for example, the "print screen" 
key on the local keyboard. The user selects the desired 

15 computer from the list using the local keyboard and/or 
mouse . 

According to Beasley, the on-screen programming 
circuit requires at least two sets of tri-state buffers, a 
single on-screen processor, an internal synchronization 
20 generator, a synchronization switch, a synchronization 
polarizer, and overlay control logic. The first set of 
tri-state buffers couples the red, green, and blue 
components of the video signals received from the remote 
computer to the video monitor. That is, when the first set 
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of tri-state buffers are energized, the red, green, and 
blue video signals are passed from the remote computer to 
the local video monitor through the tri-state buffers. 
When the first set of tri-state buffers are not active, the 
5 video signals from the remote computer are blocked. 

Similarly, the second set of tri-state buffers couples the 
outputs of the single on-screen processor to the video 
monitor. When the second set of tri-state buffers is 
energized, the video output of the on-screen programming 

10 circuit is displayed on the local video monitor. When the 
second set of tri-state buffers is not active, the video 
output from the on-screen programming circuit is blocked. 
Alternatively, if both sets of tri-state buffers are 
energized, the remote computer video signals are combined 

15 with the video signals generated by the on-screen processor 
prior to display on the local video monitor. 

The on-screen programming circuit disclosed in Beasley 
also produces its own horizontal and vertical 
synchronization signals. To dictate which characters are 

20 displayed on the video monitor, the CPU sends instructional 
data to the on-screen processor. This causes the on-screen 
processor to retrieve characters from an internal video RAM 
for display on the local video monitor. 
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The overlaid video image produced by the on-screen 
processor, namely a Motorola MC141543 on-screen processor, 
is limited to the size and quantity of colors and 
characters that are available with the single on-screen 
5 processor. In other words, the Beasley system is designed 
to produce an overlaid video that is sized for a standard 
size computer monitor (i.e., not a wall-size or multiple 
monitor type video display) and is limited to the quantity 
of colors and characters provided by the single on-screen 

10 processor. 

During operation of the Beasley system, a remote 
computer is chosen from the overlaid video display* 
Thereafter, the first signal conditioning unit receives 
keyboard and mouse signals from the local keyboard and 

15 mouse and generates a data packet for transmission to a 

central cross point switch. The cross point switch routes 
the data packet to the second signal conditioning unit, 
which is coupled to the selected remote computer. The 
second signal conditioning unit then routes the keyboard 

2 0 and mouse command signals to the keyboard and mouse 
connectors of the remote computer. Similarly, video 
signals produced by the remote computer are routed from the 
remote computer through the second signal conditioning 
unit, the cross point switch, and the first signal 



-8- 



conditioning unit to the local video monitor. The 
horizontal and vertical synchronization video signals 
received from the remote computer are encoded on one of the 
red, green or blue video signals. This encoding reduces 
5 the quantity of cables required to transmit the video 
signals from the remote computer to the local video 
monitor. 

Pinkston discloses a keyboard, video, mouse ("KVM") 
switching system capable of coupling to a standard network 

10 (e.g., a Local Area Network) operating with a standard 
network protocol (e.g., Ethernet, TCP/IP, etc.). The 
system of Pinkston couples a central switch to a plurality 
of computers and at least one user station having a 
keyboard, video monitor, and mouse. The central switch 

15 includes a network interface card ("NIC") for connecting 

the central switch to a network, which may include a number 
of additional computers or remote terminals. Utilizing the 
Pinkston system, a user located at a remote terminal 
attached to the network may control any of the computers 

20 coupled to the central switch. 

Thornton discloses a computer system having remotely 
located I/O devices. The system of Thornton includes a 
computer, a first interface device, and a remotely located 
second interface device. The first interface device is 
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coupled to the computer and the second interface device is 
coupled to a video monitor and as many as three I/O devices 
(e.g., keyboard, mouse, printer, joystick, trackball, etc.) 
such that a human interface is created. The first and 
5 second interface devices are coupled to each other via a 

four wire cable. The first interface device receives video 
signals from the connected computer and encodes the 
horizontal and vertical synchronization signals of the 
received video signals onto at least one of the red, green, 

10 and blue components of the video signal. The first 

interface device also encodes the I/O signals received from 
the connected computer into a data packet for transmission 
over the fourth wire in the four wire cable. Thereafter, 
the encoded, red, green, and blue components of the video 

15 signals and the data packet are transmitted to the second 
interface device located at the human interface. The 
second interface device decodes the encoded red, green, and 
blue components of the video signal, separates the encoded 
horizontal and vertical synchronization signals, and 

20 decodes the I/O signal data packet. The video signal and 
the synchronization signals are then output to the video 
monitor attached to the second interface and the decoded 
I/O signals are routed to the proper I/O device, also 
attached to the second interface. The second interface 



-10- 



device may optionally include circuitry to encode I/O 
signals received from the I/O devices attached to the 
second interface for transmission to the first interface 
device . 

5 Wilder discloses a keyboard, video, mouse, and power 

switching ("KYMP") apparatus for connecting a plurality of 
computers to one or more user stations having an attached 
keyboard, video monitor, and mouse. On screen display 
{"OSD") circuitry embedded within the KVMP switching 

10 apparatus allows a user located at a user station to select 
and operate any one of the computers utilizing the 
keyboard, video monitor, and mouse attached to the user 
station. Secondary switching circuitry located within the 
KVMP switching apparatus allows a user located at a user 

15 station to additionally control the electrical power supply 
supplying each computer. 

In view of the foregoing, a need clearly exists for a 
self-contained remote network management system capable of 
operating and controlling networking equipment, servers, 

20 and computers connected to a remote control switching unit. 
Furthermore, such a system should allow a user to control 
the power supply attached to the remote networking 
equipment, servers, and computers. The system should aid 
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in managing remote network environments, thereby reducing 
the need to have an on-site system administrator. 

SUMMARY OP THE INVENTION 

5 The present invention provides a self-contained remote 

network management system for administrating a remote 
computer networking environment from one or more local user 
workstations with attached peripheral devices (i.e., 
keyboard, video monitor, cursor control device, etc.). The 

10 remote network management system of the present invention 
allows a user located at a user workstation to access, 
operate, and control networking equipment, servers, and 
computers located at a remote location. The remote network 
management system also allows a user to control the power 

15 supply to each piece of remote equipment. The networking 
equipment (e.g., hubs, switches, routers, etc.) is 
typically controlled via a serial interface. In contrast, 
servers and computers are controlled and operated utilizing 
a keyboard, video monitor, and mouse. 

20 The remote networking equipment, servers, and 

computers are all connected to a central remote management 
unit ("RMU"), and in turn, the RMU is connected to the 
Internet or a LAN via an Ethernet or modem connection. The 
RMU has serial ports for connection to the networking 
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equipment as well as keyboard, video, and cursor control 
device ports for connection to the servers and computers. 
The RMU additionally contains a port for connection to a 
power supply capable of controlling the power to the 
5 networking equipment, servers, and computers. Standard 
cabling is utilized to connect the networking equipment, 
servers, and computers to the appropriate ports on the RMU. 

The RMU also provides compatibility between various 
operating systems and/or communication protocols, including 

10 but not limited to, those manufactured by Microsoft 

Corporation ("Microsoft") (Windows), Apple Computer, Inc. 
("Apple") (Macintosh), Sun Microsystems, Inc. ("Sun") 
(Solaris), Digital Equipment Corporation ("DEC"), Compaq 
Computer Corporation ("Compaq") (Alpha), International 

15 Business Machines ("IBM") (RS/6000) , Hewlett-Packard 
Company ("HP") (HP9000) and SGI (formerly "Silicon 
Graphics, Inc.") (IRIX) . 

To utilize the remote network management system of the 
present invention, a user first initiates a management 

20 session by utilizing client software located on a user 

workstation to connect to the RMU. Alternatively, the user 
may utilize an Internet browser to connect to the RMU. The 
user is then prompted by the RMU to provide a user name and 
a password. The RMU is capable of storing multiple 
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profiles and different levels of access for each profile. 
Once a user has been authenticated, the user is provided an 
option menu on the user workstation's monitor produced by 
option menu circuitry located in the RMU. The option menu 
5 consists of a menu listing all the networking equipment, 
servers, and computers at the remote location. The option 
menu additionally contains a menu allowing a user to 
control the power to each piece of remote equipment. The 
user selects the desired networking equipment, server, or 
10 computer by utilizing the keyboard and/ or cursor control 

device attached to the user workstation. Once a user makes 
a selection, the user is provided access to the remote 
equipment as if the user is physically located at the 
remote site. 

15 The RMU and the user workstation communicate via 

TCP/IP. Before transmission via TCP/IP, the unidirectional 
video signals (i.e., from the RMU to the user workstation) 
are digitized by a frame grabber. This circuit captures 
video output from the initiating computer at a speed of at 

20 least 20 frames/second and converts the captured analog 

video signals to a digital representation of pixels. Each 
pixel is digitally represented with 5 bits for red, 5 bits 
for green, and 5 bits for blue. The digital representation 
is then stored in a raw frame buffer. The compression 
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algorithm then processes the digital data contained in the 
raw frame buffer. The compression algorithm is actually a 
combination of four sub- algorithms (i.e., the Noise 
Reduction and Difference Test ("NRDT"), Smoothing, Caching, 
5 and Bit Splicing/Compression sub-algorithms) as described 
in greater detail below. 

After the video signals have arrived at the user 
workstation, decompression occurs. The user workstation 
operates as a decompression device by executing a 

10 decompression algorithm. Along with any transmitted video 
or data signals, the RMU transmits messages to the 
decompression devices regarding the portions of the video 
that yielded "cache" hits (i.e., portions of unchanged 
video) . In response, the decompression device constructs 

15 the video frame based upon the transmitted video signals 
and the blocks of pixels contained in its local cache. 
Also, the decompression device updates its local cache with 
the new blocks of pixels received from the RMU. In this 
manner, the decompression device caches remain synchronized 

20 with the compression device cache. Both the compression 

device and the decompression device update their respective 
cache by replacing older video data with newer video data. 

Furthermore, the video signals transmitted by the RMU 
have been compressed using a lossless compression 
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algorithm. Therefore, the decompression device (e.g., 
software on the user workstation) must reverse this 
lossless compression. This is done by identifying the 
changed portions of the video image, based upon flags 
5 transmitted by the RMU. From this flag information, the 
decompression device is able to reconstruct full frames of 
video. 

In addition, the decompression device converts the 
video frame to its original color scheme by reversing a 

10 color code table ("CCT") conversion. The decompression 

device, like the RMU, locally stores a copy of the same CCT 
used to compress the video data. The CCT is then used to 
convert the video data received from the RMU to a standard 
RGB format that may be displayed on the monitor attached to 

15 the user workstation. 

The decompression algorithm can be implemented in the 
remote network management system of the present invention 
in a variety of embodiments. For example, in one 
embodiment, it can be implemented as a software application 

2 0 that is executed by the user workstation. In an alternate 
embodiment, the decompression algorithm can be implemented 
to execute within a web browser such as Internet Explorer 
or Netscape® Navigator®. Such an embodiment eliminates the 
need for installation of application specific software on 
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the user workstation. Also, this embodiment allows the RMU 
to easily transmit the video signals to any user 
workstation with Internet capabilities, regardless of the 
distance at which the computer is located from the 
5 initiating computer. This feature reduces the cabling cost 
associated with the remote network management system of the 
present invention . 

Since the present invention can be used to display 
video signals at locations that may be at a great distance 

10 from the RMU, it is important to ensure that the video 

signal transmission is secure. If the transmission is not 
secure, hackers, competitors, or other unauthorized users 
could potentially view confidential information contained 
within the video signals. Therefore, the remote network 

15 management system of the present invention is designed to 
easily integrate with digital encryption techniques known 
in the art. In one embodiment of the present invention, a 
128-bit encryption technique is used both to verify the 
identity of the RMU and to encrypt and decrypt the 

20 transmitted video and data signals. In this embodiment, a 
128 -bit public key RSA encryption technique is used to 
verify the remote participant, and a 128-bit RC4 private 
key encryption is used to encrypt and decrypt the 
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transmitted signals. Of course, other encryption 
techniques or security measures may be used. 

Finally, since the remote network management system of 
the present invention allows for platform independent 
5 communications, the compression algorithm utilized does not 
employ operating system specific hooks, nor does it use 
platform specific GDI calls. 

In the preferred embodiment, the compression algorithm 
described herein and in co-pending application serial no. 
10 10/233,299 is used to transmit the video signals. However, 
the video transmission system is not limited to such an 
embodiment. Rather, this system may be employed with any 
compression algorithm without departing from the spirit of 
the invention. 

15 Therefore, it is an object of the present invention to 

provide an improved, remote network management system that 
enables a user to control a remote networking environment 
from one or more local user workstations. Such a remote 
networking environment may include domain servers, 

20 file/print servers, headless servers, network appliances, 

serial IT equipment, switches, routers, firewalls, security 
interfaces, application servers, load balancers, and 
environmental controls. 
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Further, it is an object of the present invention to 
provide a remote network management system that allows one 
or more local user workstations to access and operate 
remote networking equipment, servers, and computers 
5 connected to a remote management unit. 

It is another object of the present invention to 
provide a single, platform- independent remote network 
management system offering centralized, integrated, and 
secure control . 

10 . It is an additional object of the present invention to 

provide a network- independent remote network management 
system containing a modem for emergency access. 

It is a further object of the present invention to 
provide a remote network management system capable of BIOS- 
15 level control of KVM equipment and console -level control of 
serial devices. 

Additionally, it is an object of the present invention 
to provide a remote network management system which 
provides a single consolidated view of all servers and 
20 other connected devices from one screen via a web browser. 
It is another object of the present invention to 
provide a remote network management system which contains a 
single sign-on and interface. 
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Additionally, it is an object of the present invention 
to provide a remote network management system which is 
upgradeable . 

It is a further object of the present invention to 
5 provide a remote network management system which provideis 
high performance over low bandwidth connections including 
modem, wireless, cable, DSL, and fractional Tl. 

It is another object of the present invention to 
provide a remote network management system which utilizes a 
10 video compression algorithm and frame-grabber technology to 
ensure the fastest possible transmission of high quality 
video. 

Furthermore, it is an object of the present invention 

to provide a remote network management system including 
15 built-in serial port buffering to provide views of recent 

console history. 

It is still a further object of the present invention 

to provide a remote network management system that is easy 

to install and operate. 
20 In addition, it is an object of the present invention 

to provide a remote network management system that is 

compact and provides readily accessible communications 

ports . 
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Further, it is an object of present invention to 
provide a remote network management system, which allows 
error- free communications between peripheral devices of a 
local user workstation and networking equipment, servers, 
5 and computers located at domain servers, file/print 

searvers, headless servers, network appliances, serial IT 
equipment, switches, routers, firewalls, security- 
interfaces, application servers, load balancers, and 
environmental controls . 

10 It is also an object of the present invention to 

provide a remote network management system capable of 
controlling the power supply to remotely located networking 
equipment, servers, and computers. 

Other objects, features, and characteristics of the 

15 present invention, as well as the methods of operation and 
functions of the related elements of the structure, and the 
combination of parts and economies of manufacture, will 
become more apparent upon consideration of the following 
detailed description with reference to the accompanying 

20 drawings, all of which form a part of this specification. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A further understanding of the present invention can 
be obtained by reference to a preferred embodiment set 
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forth in the illustrations of the accompanying drawings. 
Although the illustrated embodiment is merely exemplary of 
systems for carrying out the present invention, both the 
organization and method of operation of the invention, in 
general, together with further objectives and advantages 
thereof, may be more easily understood by reference to the 
drawings and the following description. The drawings are 
not intended to limit the scope of this invention, which is 
set forth with particularity in the claims as appended or 
as subsequently amended, but merely to clarify and 
exemplify the invention. 

For a more complete understanding of the present 
invention, reference is now made to the following drawings 
in which: 

FIG. 1 is a schematic representation of a remote 
network management system according to the preferred 
embodiment of the invention illustrating the connection of 
a user workstation that includes a keyboard, video monitor, 
and cursor control device to networking equipment, servers, 
and computers through a remote management unit ("RMU") . 

FIG. 2 is a screen- shot of an example option menu 
utilized to control the networking equipment, servers and 
computers . 
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FIG. 3A is a block diagram of the preferred embodiment 
of the RMU shown in FIG. 1 according to the preferred 
embodiment of the present invention illustrating the 
internal structure of the RMU and connectors for serial 
5 devices, keyboards, video monitors, cursor control devices, 
and a power supply. 

FIG. 3B is a detailed block diagram of the serial card 
shown in FIG. 3A. 

FIG. 3C is a detailed block diagram of the KVM port 
10 header shown in FIG. 3A. 

FIG. 3D is a detailed block diagram of the video 
processor shown in FIG. 3A. 

FIG. 4 depicts a flowchart of the compression 
algorithm utilized by the preferred embodiment of the RMU 
15 in accordance with the present invention. 

FIG. 5A depicts a flowchart detailing the Noise 
Reduction and Difference Test and smoothing sub-algorithms 
of the compression algorithm utilized by the preferred 
embodiment of the present invention. 
20 FIG. 5B depicts a flowchart that details the caching 

and bit splicing/compression sub- algorithms of the 
compression algorithm utilized by the preferred embodiment 
of the present invention. 
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FIG. 6 depicts a flowchart that details the nearest 
match function and its integration with the CCT of the 
compression algorithm utilized by the preferred embodiment 
of the present invention. 
5 FIG. 7 depicts a flowchart that details the Noise 

Reduction and Difference Test sub-algorithm of the 
compression algorithm utilized by the preferred embodiment 
of the present invention. 

FIG. 8 depicts an example application of the Noise 
10 Reduction and Difference Test sub-algorithm to a sample 
block of pixels as performed by the compression algorithm 
utilized by the preferred embodiment of the present 
invention. 

FIG. 9 depicts a detailed flowchart of the operation 
15 of the decompression algorithm used by the preferred 
embodiment of the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

As required, a detailed illustrative embodiment of the 
20 present invention is disclosed herein. However, 

techniques, systems and operating structures in accordance 
with the present invention may be embodied in a wide 
variety of forms and modes, some of which may be quite 
different from those in the disclosed embodiment. 
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Consequently, the specific structural and functional 
details disclosed herein are merely representative, yet in 
that regard, they are deemed to afford the best embodiment 
for purposes of disclosure and to provide a basis for the 
claims herein which define the scope of the present 
invention. The following presents a detailed description 
of the preferred embodiment (as well as some alternative 
embodiments) of the present invention. 

Referring first to FIG. 1, depicted is the 
architecture of the preferred embodiment of a remote 
network management system in accordance with the present 
invention. Specifically, a remote network management 
system is shown comprising user workstation 101 including 
keyboard 103, video monitor 105, and cursor control device 

107, remote management unit ("RMU") 109, Internet /LAN/WAN 

108, public switched telephone network ("PSTN") 106, serial 
devices 111a and 111b, servers 113a and 113b, remote 
computers 115a and 115b, and power supply 117. Preferably, 
user workstation 101 and RMU 109 are connected to 
Internet/LAN/WAN 108 via communication lines 119 and 121, 
respectively. Although CAT 5 cabling is the preferred 
cabling for communication lines 119 and 121, other cabling 
may be used, such as coaxial, fiber optic or multiple CAT 5 
cables. CAT 5 cabling is preferred because it reduces 



cabling cost while maintaining the strength of signals that 
are transmitted over an extended distance. Alternatively, 
wireless networking equipment may also be utilized to 
connect RMU 109 to Internet/LAN/WAN 108 and serial devices 
5 111a and 111b, servers 113a and 113b, computers 115a and 

115b, and power supply 117. Similarly, wireless networking 
equipment may also be utilized to connect user workstation 
101 to Internet/LAN/WAN 108, 

In an alternate embodiment, user workstation 101 may 

10 utilize PSTN 106 to connect to RMU 109. If PSTN 109 is 

utilized to connect to RMU 109, communication lines 120 and 
122 would preferably be CAT 3 cables. As an example, this 
means of communication may be utilized in emergency 
situations, such as if Internet/LAN/WAN 108 is not 

15 functioning properly. 

Communication lines 119 and 121 are connected to user 
workstation 101 and RMU 109 by plugging each end into a RJ- 
45 socket located on the respective pieces of equipment to 
be coupled by the CAT 5 cable. Although RJ-45 sockets and 

20 plugs are preferred, other types of connector may be used, 
including but not limited to RJ-11, RG-58, RG-59, British 
Naval Connector ("BNC"), and ST connectors. 

The remote management system includes local user 
workstation 101, preferably comprising dedicated peripheral 
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devices such as keyboard 103, video monitor 105 and/or 
cursor control device 107. Other peripheral devices may 
also be located at workstation 101, such as a printer, 
scanner, video camera, biometric scanning device, 
5 microphone, etc. Each peripheral device is directly or 
indirectly connected to user workstation 101, which is 
attached to Internet/LAN/WAN 108 via communication line 
119. Of course, wireless peripheral devices may also be 
used with this system. In a preferred mode of operation, 

10 all electronic signals (i.e., keyboard signals and cursor 
control device signals) received at user workstation 101 
from attached peripheral devices are transmitted to 
Internet/LAN/WAN 108 via communication line 119. 
Thereafter, the signals are transmitted to RMU 109 via 

15 communication line 121. RMU transmits the received signals 
to the respective remote equipment, which, in this figure, 
includes serial devices 111a and 111b, servers 113a and 
113b, computers 115a and 115b, and power supply 117. 

RMU 109 may be compatible with all commonly used, 

20 present day computer operating systems and protocols, 
including, but not limited to, those manufactured by 
Microsoft (Windows) , Apple (Macintosh) , Sun (Solaris) , DEC, 
Compaq (Alpha), IBM (RS/6000) , HP (HP9000) and SGI (IRIX). 
Additionally, local devices may communicate with remote 
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computers via a variety of protocols including Universal 
Serial Bus ("USB"), American Standard Code for Information 
Interchange ("ASCII") and Recommend Standard-232 ("RS- 
232") . 

5 Serial devices 113a and 113b are connected to RMU 109 

via communication lines 112a and 112b, respectively. 
Preferably, communication lines 112a and 112b are CAT 5 
cables terminated with RJ-45 connectors. However, a 
special adapter may be required to properly connect 

10 communication lines 112a and 112b to serial devices 111a 
and 111b since not all serial devices are outfitted with 
RJ-45 ports. For example, if serial device Ilia only 
contained a serial port, the adapter would interface the 
RJ-45 connector of communication line 112a to the serial 

15 port located on serial device Ilia. 

Similarly, power supply 117 is connected to RMU 109 
via communication line 118. Preferably, communication line 
118 is a CAT 5 cable terminated with an RJ-45 connector on 
each end. 

20 Servers 113a and 113b and computers 115a and 115b are 

connected to RMU 109 via communication lines 114a, 114b, 
116a, and 116b, respectively. Preferably, communication 
lines 114a, 114b, 116a, and 116b are three-to-one coaxial 
cables which allow the keyboard, video, and cursor control 
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device ports of servers 113a and 113b and computers 115a 
and 115b to be connected to a single port on RMU 109 as 
shown. 

To connect to the remote networking environment for 
5 administration and access, a user initiates a remote 

management session at user workstation 101. The user first 
accesses client software located using workstation 101, 
which prompts the user for a user name and password. 
However, the system may utilize any combination of 

10 identification data to identify and/or authenticate a 
particular user. Utilizing the attached keyboard 103, 
cursor control device 107 or other peripheral device, the 
user enters the user name and password. Once the user name 
and password have been entered, user workstation 101 

15 connects to Internet/LAN/WAN 108 via communication line 

119. User workstation 101 may connect to Internet /LAN/WAN 
108 in a variety of ways. For example, user workstation 
101 may be connected to Internet/LAN/WAN 108 through an 
Ethernet connection. In this example, communication line 

20 119 would be a CAT 5 cable. The connection to 

Internet /LAN/WAN 108 may also be accomplished through a 
wireless connection which precludes the need for 
communication line 119. For example, RMU 109 may utilize 
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standard Wireless Fidelity ("Wi-Fi") networking equipment 
to communicate with Internet/LAN/WAN 108. 

Alternatively, user workstation 101 may connect to RMU 
109 via PSTN 106 by utilizing a modem connection. In this 
5 alternative example, communication lines 120 and 122 would 
be CAT 3 cables. 

The username and password are then routed through 
Internet/LAN/WAN 108 to RMU 109 via communication line 121. 
RMU 109 receives the username and password and 

10 authenticates the user located at user workstation 101. 

Once the user has been authenticated by RMU 109, an option 
menu circuit located in RMU 109 provides an option menu to 
user 101 via monitor 105 listing all the devices accessible 
through RMU 109. The user makes selections from this 

15 option menu utilizing keyboard 103, cursor control device 
105, or some other peripheral device attached to user 
workstation 101. 

As shown in FIG. 2, option menu 201 consists of device 
list 203, first desktop window 205, power control window 

20 207, second desktop window 209, and serial device window 

211. Device list 203 lists all active and inactive devices 
connected to RMU 109. A user utilizes this menu to select 
the desired device for control. In this example, first 
desktop window 205 displays the desktop of one of the 
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remote computers. By selecting first desktop window 205, a 
user may utilize keyboard 103, cursor control device 107, 
or some other peripheral device to control the displayed 
remote computer. In a similar manner, a user may utilize 
5 power control window 207 to access and operate power supply 
117. Power control window 207 displays a list of all 
devices connected to power supply 117 as well as the status 
of each attached device such as average power utilized, RMS 
current, RMS voltage, internal temperature, etc. Power 

10 control window 207 is primarily utilized to cycle the power 
to the devices attached to power supply 117. However, 
since power supply 117 is programmable, power control 
window 207 may be utilized to perform any functions 
possible with power supply 117. 

15 Second desktop window 209 is utilized to access and 

operate a second remote computer or server. Serial device 
window 211 is utilized to operate and access any remote 
serial device attached to remote management unit 109. 
Serial device window 211 displays the current output 

2 0 produced by the serial device as well as the previous 

output produced by the serial device. The previous output 
of the serial device is stored in a buffer located in RMU 
109. 
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Preferably, option menu 201 consists of a menu in 
which the attached devices are arranged by their connection 
to RMU 109. For example, serial devices 111a and 111b 
preferably would be listed in a menu different from servers 
5 113a and 113b and computers 115a and 115b. The option menu 
also consists of a sub-menu for controlling power supply 
117. 

RMU 109 may additionally contain an attached keyboard 
123, cursor control device 125, and video monitor 127 which 

10 allow a user local to RMU 109 to control the attached 

serial devices 111a and 111b, servers 113a and 113b, and 
computers 115a and 115b, power supply 117, etc. Keyboard 
123, cursor control device 125, and video monitor 127 may 
also be utilized to configure RMU 109 locally. Keyboard 

15 123, cursor control device 125, and video monitor 127 are 
connected to RMU 109 via interface cable 129. 
Alternatively, keyboard 123, cursor control device 125, and 
video monitor 12 7 may be connected to RMU 109 via standard 
keyboard, cursor control device, and video monitor 

2 0 connectors. 

Referring next to FIG. 3A, depicted is the preferred 
embodiment of RMU 109 according to the present invention. 
Keyboard and mouse signals arrive at RJ-45 port 201 from 
Internet/LAN/WAN 108 via communication line 121. RMU 109 
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consists of RJ-45 port 201, RJ-11 port 202, Ethernet 
connector 205, modem module 204, communications port 
connector 206, CPU 207, communications port connector 208, 
PCI riser card 209, serial card 211, video processor 212, 
5 serial ports 213, frame grabber 215, KVM port header 217, 
KYM ports 219, power supply 221, power port 223, reset 
circuitry 225, local KVM port 22 7, and option menu circuit 
229. As shown, the keyboard and/or cursor control device 
signals initially arrive at RJ-45 port 201 if RMU 109 is 

10 connected to Internet /LAN/ WAN 108 via an Ethernet 

connection. The signals are then transmitted to Ethernet 
connector 205 which depacketizes the signals. 
Alternatively, the signals may arrive from PSTN 106 at RJ- 
11 port 202 if the keyboard and/or cursor control device 

15 signals were transmitted via a modem. In this case, the 
signals are transmitted to modem module 204, which 
demodulates the received signals,, and subsequently to 
communications port connector 206 which depacketizes the 
signals . 

20 From Ethernet connector 2 05 or communications port 

connector 206, the keyboard and/or cursor control device 
signals are then transmitted to CPU 207 via video processor 
212. CPU 207 utilizes routing information contained within 
the keyboard and/or cursor control device signals to 
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determine the proper destination for the keyboard and 
cursor control device signals. If the keyboard and cursor 
control device signals specify a command to power supply 
117, CPU 207 interprets the received command (e.g., 
5 utilizing a look-up table) and sends the proper command to 
power supply 117 via communications port connector 208 and 
power port 210. Preferably, power port 210 is an RJ-45 
connector to allow the RMU to interface with a power strip 
and control it as if it were a serial device. 

10 If CPU 2 07 determines that the keyboard and cursor 

control device signals contain a serial device routing 
instruction, the keyboard and cursor control device signals 
are transmitted to serial card 211 through PCI riser card 
209. As shown in FIG. 3B, serial port 211 consists of 

15 UART/switch 301, serial transceivers 303, and programmable 
memory 305. Serial card 211 is capable of bidirectional 
signal transmission. When keyboard and/or cursor control 
device signals are being transmitted from PCI riser card 
209 to serial port 213, the signals are initially 

20 transmitted to UART/switch 301 which, utilizing data and 
logic stored in memory 305, determines the proper serial 
transceiver 3 03 to which.. the keyboard and/or cursor control 
device signals are to be sent. In the preferred embodiment 
of serial card 211, UART/switch 301 is an EXAR XR17cl58. 
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Subsequently, the analog signals are transmitted to the 
appropriate serial transceiver 303 which converts the 
signals from a parallel format to a serial format. Serial 
transceiver 303 is preferably a HIN23E serial transceiver 
5 from Intersil. The keyboard and/or cursor control device 
signals are then transmitted to serial port 213. 

In contrast, when commands from serial device 111a or 
111b are transmitted to CPU 207 via serial port 213, serial 
card 211, and PCI riser card 209, the commands are 

10 initially transmitted to serial transceiver 303 which 
converts the serial commands to a parallel format. 
Subsequently, the commands are transmitted to UART/switch 
301 which re-transmits the commands to CPU 207 via PCI 
riser card 209. CPU 207 interprets the received commands 

15 and emulates a virtual terminal for display on video 

monitor 105. The present invention may incorporate any 
number of serial ports 213. In the example shown in FIG. 
3A, two serial devices, 111a and 111b, are connected to 
serial ports 213a and 213b, respectively. 

20 If CPU 207 determines that the keyboard and/or cursor 

control device signals are meant for servers 113a and 113b 
or computers 115a and 115b, CPU 207 transmits the keyboard 
and cursor control device signals through PCI riser card 
2 09 and frame grabber 215 to KVM port header 217 which 
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transmits the signals to the appropriate KVM port 219. As 
shown in FIG. 3C, KVM port header 217 consists of switch 
350, video switch 352, and UARTs 354. When keyboard and/or 
cursor control device signals are transmitted from KVM port 
5 219 to KVM port header 217, the signals are initially 
received at UART 354. UART 354 converts the received 
serial keyboard and/or cursor control device signals to a 
parallel format. The converted keyboard and/or cursor 
control device signals are then transmitted to switch 350 

10 which retransmits the signals to frame grabber 215. 

In a similar manner, bi-directional keyboard and/or 
cursor control device signals are also transmitted from 
frame grabber 215 to KVM port 219. Keyboard and/or cursor 
control device signals received from frame grabber 215 are 

15 transmitted to switch 350 located in KVM port header 217. 
Utilizing control signals contained within the keyboard 
and/or cursor control device signals, switch 350 transmits 
the received keyboard and/or cursor control device signals 
to the appropriate UART 354. UART 354 then converts the 

2 0 keyboard and/or cursor control device signals from a 

parallel format to a serial format for transmission to KVM 
port 219. 

KVM port header 217 also transmits uni-directional 
video signals received at KVM port 219 to frame grabber 
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215. The analog video signals received from KVM port 219 
initially are transmitted to video switch 352. Video 
switch 352 then retransmits the video signals to frame 
grabber 215 which converts the received analog video 
5 signals to a digital format. 

Turning to FIG. 3D, after the video signals have been 
digitized by frame grabber 215, the digitized video signals 
are transmitted to video processor 212 via CPU 207. Video 
processor 212 consists of video-in port 370, R-out 376a, G- 

10 out 376b, B-out 376c, pixel pusher 378,. frame buffers 380, 
compression device 382, flash memory 384, RAM 386, 
microprocessor 388, and switch 390. Shown at the top of 
FIG. 3D, video-in port 370 receives the digitized video 
signals from CPU 207. The outputs of video-in port 370 are 

15 shown as R-out 376a, G-out 376b, and B-out 376c, which 
represent the red component, green component, and blue 
component of the digitized video signal, respectively. 
Video-in port 370 outputs these digitized video signal 
components in the form of pixels, which are transmitted to 

20 and stored in pixel pusher 378. Pixel pusher 378, flash 
memory 384, and Random Access Memory ("RAM") 386 
communicate with microprocessor 388 via communication bus 
387. Pixel pusher 378 also communicates with frame buffers 
380 (e.g., raw frame buffer, compare frame buffer, etc.) 
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and compression device 382 via communication buses 379 and 
381, respectively. The compression algorithm is executed 
by microprocessor 388. Generally, the compression operates 
as follows: 
5 Noise Reduction and Difference Test: 

As discussed above, digitization of the analog video 
signals is necessary to allow these signals to be 
transmitted via a digital communication medium (e.g., a 
network, LAN, WAN, Internet, etc.). However, a detrimental 

10 side effect of the digitization process is the introduction 
of quantization errors and noise into the video signals. 
Therefore, the Noise Reduction and Difference Test sub- 
algorithm ("NRDT sub-algorithm") is designed to reduce the 
noise introduced during the digitization of the video 

15 signals. In addition, the NRDT sub-algorithm 

simultaneously determines the differences between the 
recently captured frame of video (i.e., the "current 
frame") and the previously captured frame of video (i.e., 
the "compare frame"). 

20 First, the NRDT sub-algorithm divides the current 

frame, which is contained in the raw frame buffer, into 64 
X 32 blocks of pixels. Alternatively, other sizes of 
blocks may be used (e.g., 8x8 pixels, 16x16 pixels, 32x32 
pixels, etc.) based upon criteria such as the size of the 
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entire video frame, the bandwidth of the communication 
medium, desired compression yield, etc. 

After the current frame is divided into blocks, a two- 
level threshold model is applied to the block of pixels to 
5 determine whether it has changed with respect to the 
compare frame. These two thresholds are the "pixel 
threshold" and the "block threshold." 

First, a given pixel is examined and the value of each 
of the three colors (i.e., red, green, and blue) of the 

10 pixel is calculated with the value of its corresponding 
pixel in the compare frame. From this calculation, a 
distance value is computed. If the distance value is 
greater than the pixel threshold (i.e., the first threshold 
of the two- level threshold) , this distance value is added 

15 to a distance sum. This process is performed for each 
pixel in the block. 

Next, after the distance value of all of the pixels in 
the block have been calculated and processed in the 
aforementioned manner, the resulting value of the distance 

20 sum is compared to the block threshold (i.e., the second 

threshold of the two- level threshold) . If the distance sum 
exceeds the block threshold, then this block of pixels is 
considered changed in comparison to the corresponding block 
of pixels in the compare frame. If a change is determined, 
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the compare frame, which is stored in the compare frame 
buffer, will be updated with the new block of pixels. 
Furthermore, the new block of pixels will be further 
processed and transmitted in a compressed format to the 
5 user workstation. 

In contrast, if the distance sum is not greater than 
the block threshold, the block of pixels is detennined to 
be unchanged. Consequently, the compare frame buffer is 
not updated, and this block of pixels is not transmitted to 

10 the user workstation. Eliminating the transmission of 

unchanged blocks of pixels reduces the overall quantity of 
data to be transmitted, thereby increasing transmission 
time and decreasing the required bandwidth. 

The NRDT sub-algorithm is ideal for locating both a 

15 large change in a small quantity of pixels and a small 

change in a large quantity of pixels. Consequently, the 
NRDT sub-algorithm is more efficient and more accurate than 
known percentage threshold algorithms that simply count the 
number of changed pixels in a block of pixels. With such 

20 an algorithm, if a few pixels within the block of pixels 
have changed drastically (e.g., from black to white), the 
algorithm would consider the block of pixels to be 
unchanged since the total number of changed pixels would 
not exceed the percentage threshold value. This result 
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will often lead to display errors in the transmission of 
computer video. 

Consider, for example, a user that is editing a 
document. If the user were to change a single letter, such 
5 as changing an "E" to an "F", only a few pixels of the 

video image would change. However, based upon this change, 
the resulting document is dramatically different than the 
original document . A percentage threshold algorithm would 
not register this change and, therefore, would lead to a 

10 display error. A percentage threshold algorithm, by only 
looking at the number of pixels within a block that have 
changed, generally fails to recognize a video image change 
in which a few pixels have changed substantially. However, 
the NRDT sub-algorithm used by the present invention, by 

15 virtue of its two-level threshold, will recognize that such 
a block of pixels has significantly changed between 
successive frames of video. 
Smoothing: 

When the NRDT sub-algorithm determines that a block of 
20 pixels has changed, the digital data that represents this 
block is further processed by a smoothing sub-algorithm. 
This sub-algorithm reduces the noise introduced during the 
analog- to-digital conversion. 
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First, each digital pixel representation is converted 
to a representation that uses a lower quantity of bits for 
each pixel. It is known in the art to compress color video 
by using a fewer number of bits to represent each color of 
5 each pixel. For example, a common video standard uses 8 
bits to represent each of the red, green, and blue 
components of a video signal. Because 24 total bits are 
used to represent a pixel, this representation is commonly 
referred to as "24 bit RGB representation". If only the 

10 four most significant bits of the red, green, and blue 

components of the pixel are used to represent its color in 
lieu of all eight bits, the size of the data used to 
represent the block of pixels, and thus a frame of video, 
is reduced by fifty percent. 

15 This method of compression is simple and generally 

degrades the quality of the video. In contradistinction, 
the smoothing sub-algorithm of the present invention 
incorporates a more intelligent method of compression. 
This method uses a Color Code Table ("CCT") to map specific 

20 RGB representations to more compact RGB representations. 
Both the compression and decompression algorithms of the 
present invention use the same CCT. However, different 
color code tables may be chosen depending on the available 
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bandwidth, the capabilities of the local display device, 
etc. 

For each block of pixels, a histogram of pixel values 
is created and sorted by frequency such that the smoothing 
5 sub-algorithm may determine how often each pixel value 
occurs. Pixel values that occur less frequently are 
compared to pixel values that occur more frequently. To 
determine how similar pixel values are, a distance value is 
calculated based upon the color values of the red, green, 

10 and blue ("RGB") components of each pixel. During the 
histogram analysis, a map of RGB values to color codes 
(i.e., a CCT) is created. If a less frequently occurring 
pixel value needs to be adjusted to a similar, more 
frequently occurring pixel value, the CCT is used to map 

15 the less frequently occurring pixel value to the color code 
of the more frequently occurring pixel value. Thus, the 
noise is efficiently removed from each block and the number 
of bits used to represent each pixel is reduced. 

For illustrative purposes, suppose that an 8x8 pixel 

2 0 block is being processed. Further suppose that of the 64 
pixels in the current block, 59 are blue, 4 are red, and 1 
is light blue. Further assume that a low frequency 
threshold of 5 and a high frequency threshold of 25 are 
used. In other words, if a pixel value occurs less than 5 
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times within a block, it is considered to have a low 
frequency. Similarly, if a pixel value occurs more than 25 
times within a block, it is considered to have a high 
frequency. In the preferred embodiment of the present 
5 invention, the smoothing sub-algorithm ignores pixel values 
occurring between these two thresholds. Therefore, in the 
present example, the smoothing sub-algorithm determines 
that the red and light blue pixels occur with low 
frequency, and the blue pixels occur with high frequency. 

10 In the next step, the values of the 4 red pixels and 

the 1 light blue pixel are compared with the value of the 
59 blue pixels. In this step, a pre-determined distance 
threshold is used. If the distance between the less 
frequent pixel value and the more frequent pixel value is 

15 within this distance threshold, then the less frequent 

pixel value is converted to the more frequent pixel value. 
Therefore, in our present example, it is likely that the 
light blue pixel is close enough in value to the blue pixel 
that its distance is less than the distance threshold. 

20 Consequently, the light blue pixel is mapped to the blue 

pixel. In contrast, it is likely that the distance between 
the red and blue pixels exceeds the distance threshold and, 
therefore, the red pixel is not mapped to the blue pixel. 
With the smoothing sub-algorithm of the present invention, 
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although the red pixels occur rarely, the distance between 
the red pixel value and the blue pixel value is large 
enough that the red pixels are not converted to blue 
pixels. In this manner, the smoothing sub-algorithm of the 
5 present invention increases the redundancy in compared 

images by eliminating changes caused by superfluous noise 
introduced during the analog-to-digital conversion while 
retaining real changes in the video image. 
Caching: 

10 

After the smoothing sub-algorithm has been applied to 
the digital video image data, an optional caching sub- 
algorithm may be applied to further minimize the bandwidth 
required for transmitting the video images. The caching 

15 sub-algorithm uses a cache of previously transmitted blocks 
of pixels. Similar to the NRDT sub-algorithm, the caching 
sub-algorithm is performed on a block of pixels within the 
video frame. Again, any block size may be used (e.g., 8x8, 
16x16, 32x32 or 64x32). 

20 First, the caching sub-algorithm performs a cache 

check, which compares the current block of pixels with 
blocks of pixels stored in the cache. The size of the 
cache may be arbitrarily large. Large caches generally 
yield a higher percentage of "cache hits." However, memory 

25 and hardware requirements increase when the size of the 
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cache is increased. Furthermore, the number of 
comparisons, and thus the processing power requirements, 
also increases when the size of the cache increases. 

A "cache hit" occurs when a matching block of pixels 
5 is located within the cache. A "cache miss" occurs if a 

matching block of pixels is not found in the cache. When a 
cache hit occurs, the new block of pixels does not have to 
be retransmitted. Instead, a message and a cache entry 
identification ("ID") are sent to the remote participant 

10 equipment. Generally, this message and cache entry ID will 
consume less bandwidth than that required to transmit an 
entire block of pixels. 

If a "cache miss" occurs, the new block of pixels is 
compressed and transmitted to the user workstation. Also, 

15 both the RMU and user workstation update their respective 
cache by storing the new block of pixels in the cache. 
Since the cache is of limited size, older data is 
overwritten. One skilled in the art is aware that various 
algorithms can be used to decide which older data should be 

20 overwritten. For example, a simple algorithm can be 

employed to overwrite the oldest block of pixels within the 
cache, wherein the oldest block is defined as the least 
recently transmitted block. 
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In order to search for a cache hit, the new block of 
pixels must be compared with all corresponding blocks of 
pixels located within the cache. There are several ways in 
which this may be performed. In one embodiment, a cyclic 
5 redundancy check ("CRC") is computed for the new block of 
pixels and all corresponding blocks of pixels. The CRC is 
similar to a hash code for the block. A hash code is a 
smaller, yet unique, representation of a larger data 
source. Thus, if the CRCs are unique, the cache check 

10 process can compare CRCs for a match instead of comparing 
the whole block of pixels. If the CRC of the current block 
of pixels matches the CRC of any of the blocks of pixels in 
the cache, a "cache hit" has been found. Because the CRC 
is a smaller representation of the block, less processing 

15 power is needed to compare CRCs. Furthermore, it is 

possible to construct a cache in which only the CRCs of 
blocks of pixels are stored at the remote participant 
locations. Thus, comparing the CRCs in lieu of comparing a 
full block of pixels saves processor time and thus improves 

2 0 performance . 

Bit Splicing/Compression: 

Once the NRDT, smoothing, and optional caching sub- 
algorithms are performed, each block of pixels that must be 

25 transmitted is compressed. In the preferred embodiment of 
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the present invention, each block is compressed using the 
Joint Bi-level Image Group ("JBIG") lossless compression 
algorithm. 

The JBIG compression algorithm was designed for black 
5 and white images, such as those transmitted by facsimile 
machines. However, the compression algorithm utilized by 
the present invention can compress and transmit color video 
images. Therefore, when utilizing the JBIG compression 
algorithm, the color video image must be bit-sliced, and 

10 the resulting bit -planes must be compressed separately. 

A bit plane of a color video image is created by 
extracting a single bit from each pixel color value in the 
color video image. For example, if 8 bits are used to 
represent the color of the pixel, then the color video 

15 image is divided into 8 bit planes. The compression 

algorithm, in conjunction with the CCT discussed above, 
transmits the bit plane containing the most significant 
bits first, the bit plane containing the second most 
significant bits second, etc. The CCT is designed such 

20 that the most significant bits of each pixel color are 
stored first and the lesser significant bits are stored 
last. Consequently, the bit planes transmitted first will 
always contain the most significant data, and the bit 
planes transmitted last will always contain the least 
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significant data. Thus, the remote video monitor will 
receive video from the RMU progressively, receiving and 
displaying the most significant bits of the image before 
receiving the remaining bits. Such a method is less 
5 sensitive to changes in bandwidth and will allow a user to 
see the frame of video as it is transmitted, rather than 
waiting for all details of the frame to be sent. 

After compression of the video signals is complete, 
the resulting video signals are transmitted to either 

10 Ethernet connector 205 or communications port connector 206 
via switch 390. 

Referring back to FIG. 3A, RMU 109 also contains a 
power supply 221 which provides power to RMU 109. 
Preferably, power supply 221 is a redundant power supply 

15 which contains backup circuitry in case the main circuitry 
fails. Power supply 221 receives power through power port 
223 from an external power supply. The power to RMU is 
controlled by reset circuitry 225 which is interfaced 
directly to CPU 207. Reset circuitry 225 is utilized to 

20 turn the power on/off and reset RMU 109. 

RMU 109 also contains local KVM port 227 interfaced to 
CPU 207. Local KVM port 227 allows for connection of local 
keyboard 123, video monitor 127, and cursor control device 
125 to RMU 227 via cable 129 (FIG. 1). Local keyboard 123, 
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video monitor 127, and cursor control device 125 may be 
utilized for onsite control of the attached serial devices 
111a and 111b, servers 113a and 113b, computers 115a and 
115b, and power supply 117. 
5 Option menu circuit 229, under control of CPU 207, 

provides the option menu to a user of the present 
invention. As previously discussed, the option menu 
contains menus for selecting a serial device, a remote 
server or computer, or options to control the power to all 

10 devices connected to power supply 117. 

To utilize the system of the present invention, a user 
first initiates a remote management session at user 
workstation 101 and enters the required username and 
password. However, any unique combination of 

15 authentication information may be utilized. User 

workstation 101 packetizes the entered information and 
routes it to Internet /LAN/WAN 108 via communication line 
119 and then to RMU 109 via communication line 121. The 
entered data is received at CPU 207 via RJ-45 connector 201 

20 (or alternatively RJ-11 connector 202) . Ethernet connector 
205 removes the network protocol and transmits the received 
keyboard and/or cursor control device signals to CPU 207. 
CPU 207 utilizes a lookup table containing all user 
profiles stored in the system to authenticate the user. 
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Different user profiles may be given different levels of 
access to the system. For example, certain users may only 
be able to access and operate computers 115a and 115b and 
be restricted from operating servers 113a and 113b, serial 
5 devices 111a and 111b, and power supply 117. 

Once a user has been authenticated, option menu 
circuit 229 produces an option menu containing all the 
devices attached to RMU 109. In this case, the attached 
devices include serial devices 111a and 111b, servers 113a 

10 and 113b, computers 115a and 115b, and power supply 117. 
However, it would be apparent to one skilled in the art 
that RMU 109 may accommodate any number of serial devices, 
servers, computers, and associated power supplies. The 
option menu produced by option menu circuit 22 9 is 

15 compressed by video processor 212 and packet ized by 
Ethernet connector 205 and then transmitted to user 
workstation 101 through RJ-45 connector 201, communication 
line 121, Internet/ LAN/ WAN 108, and communication line 119, 
in that order. The option menu is depacketized and 

2 0 decompressed at user workstation 101 for display on video 
monitor 105. The user then utilizes keyboard 103 and 
cursor control device 107 to select the desired device from 
the option menu. The user-entered keyboard and cursor 
control device signals are then encoded by user workstation 
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101, transmitted to RMU 109 via Internet/LAN/WAN 108, and 
subsequently decoded by CPU 207 located in RMU 109. CPU 
207 interprets the received keyboard and cursor control 
device signals and interfaces the user with the selected 
5 device as previously described. 

If the user selects to be interfaced with servers 113a 
or 113b or computers 115a and 115b, the video signal of the 
selected device is displayed on video monitor 105. The 
video signal initially arrives from the selected device at 

10 KVM port 219 and is routed to KVM port header 217. The 
video signal is then routed to frame grabber 215 which 
converts the analog video signal to a digital signal. The 
resulting digitized video signal is then routed to CPU 207 
through PCI riser card 209. CPU 207 then determines the 

15 correct location to transmit the video signal (i.e., to 

local KVM port 227 or video processor 212) . If the video 
signal is routed to local KVM port 227, the video signal is 
displayed on local video monitor 127. Alternatively, if 
the video signal is routed to video processor 212, it is 

20 compressed by video processor 212 and packetized by either 
Ethernet connector 205 or communications port connector 206 
for transmission via communication line 121 through either 
RJ-45 port 201 or RJ-11 port 202. Ethernet connector 205 
or communications port connector 206. also appends any other 
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signals (i-e., keyboard signals, cursor control device 
signals, etc.) onto the compressed video signal for 
transmission to user workstation 101. 

To switch to another connected device, the user 
5 presses a "hotkey" such as "printscreen" or "Fl" on 

keyboard 103 attached to user workstation 101 (FIG. 1) . 
This causes option menu 229 to open an option menu allowing 
the user to select a new serial device, server, computer, 
or modify the power supply to one of the connected devices. 

10 Referring now to FIG. 4, depicted is a flowchart 

illustrating the operation of the compression algorithm 
utilized by video processor 212 in the preferred embodiment 
of the present invention. The compression algorithm is 
executed internal to RMU 109 by video processor 212 (FIG. 

15 3) . The digitized video signal is initially stored in a 
raw frame buffer (step 402) , which is one of the frame 
buffers 380 (FIG. 3D) . At this point, the compression 
algorithm is performed to process the captured video data 
contained in the raw frame buffer and prepare it for 

20 transmission to user workstation 101. 

The first step of the compression algorithm is the 
NRDT (step 4 03) . The NRDT sub -algorithm is also executed 
internal to RMU 109 by video processor 212 (FIG. 3) . The 
NRDT sub-algorithm determines which blocks of pixels, if 
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any, have changed between the current frame and the compare 
frame, also discussed above. 

In the preferred embodiment, the video frame is first 
divided into 64x32 pixel blocks. Subsequently, the NRDT 
5 sub-algorithm is applied to each block of pixels 

independently. Alternative embodiments of the present 
invention may utilize smaller or larger blocks depending on 
criteria such as desired video resolution, available 
bandwidth , et c . 

10 Next, the NRDT sub-algorithm employs a two- threshold 

model to determine whether differences exist between a 
block of pixels in the current frame and the corresponding 
block of pixels in the compare frame. These two thresholds 
are the pixel threshold and the block threshold. 

15 First, each pixel of the pixel block is examined to 

determine if that pixel has changed relative to the 
corresponding pixel of the corresponding block in the 
compare frame. The distance value of each of the three 
colors (i.e., red, green, and blue) of each pixel in 

20 relation to the corresponding compare pixel is calculated, 
as described in greater detail below with respect to FIG. 
7. If the distance value is larger than the pixel 
threshold (i.e., the first threshold of the two- threshold 
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model) , this distance value is added to a distance sum 
value . 

Then, after all pixels within the pixel block have 
been examined, if the resulting distance sum value is 
5 greater than the block threshold (i.e., the second 
threshold of the two- threshold model) , the block is 
determined to have changed. Every block of pixels in the 
video frame undergoes the same process. Therefore, after 
this process has been applied to an entire video frame, the 

10 process will have identified all pixel blocks that the 
process has determined have changed since the previous 
video frame. At this point, the compare frame is updated 
with the changed pixel blocks. However, the pixel blocks 
of the compare frame that correspond to unchanged pixel 

15 blocks of the current frame will remain unchanged. In this 
manner, the two- threshold model used by the NRDT sub- 
algorithm eliminates pixel value changes that are 
introduced by noise created during the analog to digital 
conversion and also captures the real changes in the video 

20 frame. 

After the video data is processed by the NRDT sub- 
algorithm, it is next processed by the smoothing sub- 
algorithm (step 419) . The smoothing sub-algorithm is 
designed to create a smooth, higher-quality video image by 
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reducing the roughness of the video image caused by noise 
introduced during the analog to digital conversion. 

The smoothing sub- algorithm first converts the pixel 
representation that resulted from the NRDT sub-algorithm 
5 into a pixel representation that uses a lesser quantity of 
bits to represent each pixel. This is performed using a 
CCT that is specially organized to minimize the size of the 
pixel representation. The smoothing sub-algorithm uses the 
CCT to choose color codes with the least number of 1-bits 

10 for the most commonly used colors. For example, white and 
black are assumed to be very common colors. Thus, white is 
always assigned 0 and black is always assigned 1. That is, 
white will be represented by a bit value of 0 on all 
planes. Black, the next most common color, will show up as 

15 a bit value of 1 on all but one plane. This reduces the 
quantity of data to be compressed by the compression 
algorithm. Then, for each pixel in the block, a color code 
is assigned. Simultaneously, a histogram of color codes is 
created to store the number of occurrences of each of the 

20 unique colors in the block of pixels. This histogram of 

color codes is then sorted to produce a list of color codes 
from the least number of occurrences to the dominant number 
of occurrences . 
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Once the sorted list of color codes is created, the 
next step is to merge colors. Working from the beginning 
of the sorted list, the smoothing sub-algorithm compares 
the least frequently occurring colors to the more 
5 frequently occurring colors. If the less frequently 
occurring color is very similar to a more frequently 
occurring color, then the pixels having the less frequently 
occurring color will be changed to the more frequently 
occurring color. Determination of whether two colors are 
10 similar is performed by calculating the distance between 

the three-dimensional points of the RGB space. The formula 
is : 



where D is the distance, Ri is the red value of the low 
15 frequency pixel, R2 is the red value of the high frequency 
pixel, Gi is the green value of the low frequency pixel, G2 
is the green value of the high frequency pixel, Bi is the 
blue value of the low frequency pixel, and B2 is the blue 
value of the high frequency pixel. If the distance is 
20 within a distance threshold, the two colors are determined 
to be similar. In the preferred embodiment of the present 
invention, system performance is increased by squaring the 
distance threshold and comparing this value with the sum of 
the squares of the RGB differences. This step eliminates 
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taking the square root of the sura, which requires a greater 
amount of processing time. 

Each block of pixels is filtered for noise and 
translated from a RGB representation to a color code 
5 representation. The noise that is introduced by LCD 

controller 215 (FIG. 3) during conversion of the analog 
signals to digital signals distorts the values of some 
pixels. Thus, the smoothing sub-algorithm corrects 
distorted pixels. The smoothing sub-algorithm minimizes 

10 noise by reducing the number of different colors present in 
each video image block. Further, such smoothing creates an 
image with greater redundancy, thus yielding higher 
compression ratios. 

After smoothing, caching is performed (step 421) . 

15 Caching is a sub-algorithm of the overall compression 

algorithm executed by video processor 212 of RMU 109 (FIG. 
3) . Caching requires RMU 109 (FIG. 3) to retain a cache of 
recently transmitted images. Such a cache can be 
implemented and stored in RAM 386 (FIG. 3D) . The caching 

20 sub-algorithm compares the most recent block of pixels with 
the corresponding block of pixels in the video images 
stored in the cache (step 405) . If the most recently 
transmitted block of pixels is the same as one of the 
corresponding blocks of pixels stored in the cache, the 
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caching sub-algorithm does not retransmit this portion of 
the video image. Instead, a "cache hit" message is sent to 
user workstation 101, which indicates that the most 
recently transmitted block is already stored in the cache 
5 (step 407) . The "cache hit" message contains information 
regarding which cache contains the corresponding block of 
pixels, thereby allowing user workstation 101 to retrieve 
the block of pixels from its cache and use it do create the 
video image to be displayed on its attached video display 
10 device. 

The next step in the process, step 4 09, determines if 
the NRDT determined that the block of pixels has changed 
since the corresponding block of pixels in the compare 
frame. This step can also be implemented before or in 

15 parallel with step 405. Also, steps 421, 405, and 407 may 
be eliminated entirely. 

The main purpose of step 409 is to determine whether 
the block has changed since the last frame. If the block 
has not changed, there is no need to send an updated block 

20 to user workstation 101. Otherwise, if the block of pixels 
has changed, it is prepared for compression (step 411) . In 
the preferred embodiment, step 409 uses a different 
technique than step 4 05. With two ways of checking for 
redundancy, higher compression will result. Both steps 409 
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and 411 are executed by a caching sub -algorithm executed by 
microprocessor 388 of video processor 212 (FIG. 3D) . 

For any areas of the image that have changed, the 
cache is updated, and the data is compressed before being 
5 sent to the server stack.. In the preferred embodiment, the 
image is compressed using the IBM JBIG compression 
algorithm. JBIG is designed to compress black and white 
images. However, the present invention is designed to 
transmit color video images. Therefore, bit planes of the 

10 image are extracted (step 411) , and each bit plane is 

compressed separately (step 413) . Finally, the compressed 
image is transmitted to server stack 417 (step 415) , which 
transmits the data to switch 390 (FIG. 3D) . 

FIG. 5A and FIG. 5B provide detailed flowcharts of a 

15 preferred embodiment of the compression process. The 
digital representation of the captured video image is 
transferred and stored in either frame buffer 0 503 or 
frame buffer 1 505. A frame buffer is an area of memory 
that is capable of storing one frame of video. The use of 

2 0 two frame buffers allows faster capture of image data. The 
captured frames of video are stored in frame buffer 0 503 
and frame buffer 1 505 in an alternating manner. This 
allows the next frame of video to be captured while 
compression is being performed on the pirevious firame of 
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video. In video processor 212, frame buffer 0 503 and 
frame buffer 1 505 comprise a portion of frame buffers 380 
(FIG. 3D) . 

An NRDT test is performed on each block of pixels 
5 stored in frame buffer 0 503 and frame buffer 1 505 (step 
519) , which compares each block of the captured video image 
to the corresponding block of the previously captured video 
image. Step 519 compares blocks of pixels from the video 
image stored in the current raw frame buffer (i.e., frame 

10 buffer 0 503 or frame buffer 1 505) with the corresponding 
block of pixels stored in compare frame buffer 521. This 
step is discussed in greater detail below with respect to 
FIGS. 6A and 6B. 

If step 519 determines that the current block of 

15 pixels has changed, then nearest color match function 

processes the video images contained in frame buffer 0 503 
and frame buffer 1 505 (step 509) in conjunction with the 
information contained in the client color code table ("CCT 
from client") 511, which is stored in flash memory 239 

20 (FIG. 3) . The nearest color match function can be executed 
as software by microprocessor 388. A detailed explanation 
of the nearest color match function is provided below with 
respect to FIG. 6. 
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The CCT obtained from CCT 513 by the nearest color 
match function is used for color code translation (step 
515) , which translates the digital RGB representation of 
each pixel of the changed block of pixels to reduce the 
5 amount of digital data required to represent the video 

data. Color code translation (step 515) receives blocks of 
pixels that the NRDT sub-algorithm (step 519) has 
determined have changed relative to the previous captured 
video image. Color code translation then translates this 

10 digital data into a more compact form and stores the result 
in coded frame buffer 517. Coded frame buffer 517 can be 
implemented as a portion of RAM 386 (FIG. 3D) . 

Alternatively, steps 509 and 515 may be performed in 
parallel with step 519. Performing these steps in parallel 

15 reduces the processing time required for each block of 

pixels that has changed. In this scenario, steps 509 and 
515 are performed in anticipation of the block of pixels 
having changed. If this is the case, the processing for 
steps 509 and 515 may be completed at the same time as the 

20 processing for step 519 is completed. Therefore, the 
algorithm may move directly to step 523 from step 509 
without having to wait for the processing of steps 509 and 
515. Otherwise, if step 519 determines that the block of 
pixels has not changed, and therefore the results of steps 



-62- 



509 and 515 are not required, these results may simply be 
discarded. 

Upon completion of step 515, caching begins by 
performing a cyclical redundancy check (CRC) (step 523) . 
5 Cyclic redundancy check (CRC) is a method known in the art 
for producing a checksum or hash code of a particular block 
of data. The CRCs may be computed for two blocks of data 
and then compared. If the CRCs match, the blocks are the 
same. Thus, CRCs are commonly used to check for errors. 

10 In the present invention, the CRC is used to compare a 
block of pixels with blocks of pixels stored in a cache. 
Thus, in step 523, the CRC is computed for each block of 
pixels that was determined to have changed by the NRDT sub- 
algorithm. The array of CRCs is stored in CRC array 525. 

15 Turning next to FIG. 5B, depicted is an overview of 

the caching and bit splicing/compression sub- algorithms . 
This portion of the algorithm begins waiting for 
information from coded frame buffer 517 and CRC array 525 
(step 527) . Next, a decision is made as to whether a new 

20 video mode has been declared (step 529) . A new video mode 
can be declared if, for example, user workstation 101 has 
different bandwidth or color requirements. If a new video 
mode has been declared, all data is invalidated (step 531) 
and the sub-algorithm returns to step 527 to wait for new 
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information from coded frame buffer 517 and CRC array 525. 
Downscaler circuit 362 and/or upscaler circuit 364, located 
in LCD controller 215, may be utilized to adjust the 
outputted digitized video to be compatible with the new 
5 video mode. Steps 527, 529, and 531 are all steps of the 
overall compression algorithm that is executed by 
microprocessor 388 (FIG. 3D) . 

If in step 529 it is deemed that a new video mode has 
not been declared, then the comparison of the current block 

10 of pixel's CRC with the cached CRCs is performed (step 
533) . This block compares the CRC data of the current 
video frame contained in CRC array 525 with the cache of 
previous CRCs contained in block info array 535. Block 
info array 535 stores the cache of pixel blocks and the 

15 CRCs of the pixel blocks and can be implemented as a device 
in RAM 386 (FIG. 3D) . Step 533 is also a part of the 
overall compression algorithm executed by microprocessor 
388 (FIG. 3D) . 

Next, if the current block of pixels is located within 
20 the pixel block cache contained in block info array 535 

(step 537) , a cache hit message is sent to user workstation 
101 and the block of pixels is marked as complete, or 
processed (step 539) . Since user workstation 101 contains 
the same pixel block cache as RMU 109 (FIG. 3D) , the cache 
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hit message simply directs user workstation 101 to use a 
specific block of pixels contained in its cache to create 
the portion of the video image that corresponds to the 
processed block of pixels. 
5 Next, a check is performed for unprocessed blocks of 

pixels (step 539) . All blocks of pixels that need to be 
processed, or updated, are combined to create a compute 
next update rectangle. If there is nothing to update 
(i.e., if the video has not changed between frames), then 

10 the algorithm returns to step 527 (step 543) . Thus, the 

current frame will not be sent to the remote participation 
equipment. By eliminating the retransmission of a current 
frame of video, the sub-algorithm reduces the bandwidth 
required for transmitting the video. 

15 If, however, there are areas of the image that need to 

be updated, the update rectangle is first compressed. . The 
update rectangle must first be bit sliced (step 545) . A 
bit plane of the update rectangle is constructed by taking 
the same bit from each pixel of the update rectangle. 

20 Thus, if the update rectangle includes 8-bit pixels, it can 
be deconstructed into 8 bit planes. The resulting bit 
planes are stored in bit plane buffer 547. Again, steps 
541, 543, and 545 are all part of the bit 
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splicing/compression sub-algorithm executed by 
microprocessor 388 of RMU 109 (FIG. 3) . 

Each bit plane is compressed separately by the 
compression sub-algorithm (step 549) . In this case, 
5 compression is performed on each bit plane and the 

resulting data is sent to server stack 417 (step 551) . In 
the preferred embodiment, compression is performed by video 
compression device 382 (FIG. 3) (step 549) . Thereafter, 
the compressed bit planes are sent to switch 390 (FIG. 3D) . 

10 Since the preferred embodiment captures frames 2 0 

times per second, it is necessary to wait 300 ms between 
video frame captures. Thus, the algorithm waits until 300 
ms have passed since the previous frame capture before 
returning the sub-algorithm to step 527 (step 553) . 

15 Referring now to FIG. 6, illustrated is the nearest 

color match function (step 509 of FIG. 5A) that selectively 
maps less frequently occurring colors to more frequently 
occurring colors using a CCT. Nearest color match function 
509 processes each block of pixels of the video image 

20 stored in frame buffer 0 503 or frame buffer 1 505 

successively. As shown in FIG. 6, a block of pixels is 
extracted from the video image stored in frame buffer 0 503 
or frame buffer 1 505 (step 600) . In the preferred 
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embodiment, the extracted block has a size of 64 by 32 
pixels, however, any block size may be utilized. 

The nearest color match function eliminates noise 
introduced by the A/D conversion by converting less 
5 frequently occurring pixel values to similar, more 

frequently occurring pixel values. The function utilizes 
histogram analysis and difference calculations. First, 
nearest color match function 509 generates a histogram of 
pixel values (step 601) . The histogram measures the 

10 frequency of each pixel value in the block of pixels 

extracted during step 600. The histogram is sorted, such 
that a list of frequently occurring colors (popular color 
list 603) and a list of least frequently occurring colors 
(rare color list 605) are generated. The threshold for 

15 each list is adjustable. 

Then, nearest color match function 509 analyzes each 
low frequently occurring pixel to determine if the pixel 
should be mapped to a value that occurs often. First, a 
pixel value is chosen from rare color list 605 (step 607) . 

20 Then, a pixel value is chosen from popular color list 603 
(step 609) . These distance between these two values is 
then computed (step 611) . In this process, distance is a 
metric computed by comparing the separate red, green and 
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blue values of the two pixels. The distance value D may be 
computed in a variety of ways. One such example is: 

D = (R, - R/ + (G, - + (B, - 
In this formula, Rl is the red value of the low frequency 
5 pixel, R2 is the red value of the high frequency pixel, Gl 
is the green value of the low frequency pixel, G2 is the 
green value of the high frequency pixel, Bl is the blue 
value of the low frequency pixel, and B2 is the blue value 
of the high frequency pixel . 

10 This formula yields a distance value, D, which 

indicates the magnitude of the similarity or difference of 
the colors of two pixels, such as a less frequently 
occurring pixel versus a more frequently occurring pixel. 
The goal of the sub-algorithm is to find a more frequently 

15 occurring pixel having a color that yields the lowest 
distance value when compared to the color of a less 
frequently occurring pixel. Therefore, a comparison is 
performed for each computed distance value (step 613) . 
Every time a distance value is computed that is less than 

20 all previous distance values, the distance value is written 
to the closest distance variable (step 615) . 

Once it is determined that all more frequently 
occurring pixels have been compared to less frequently 
occurring pixels (step 617) , a computation is performed to 



determine if the lowest occurring D is within a predefined 
threshold (step 619) . If this D is within the predefined 
threshold, CCT 513 is updated by mapping the low frequently 
occurring pixel to the color code value of the high 
5 frequently occurring pixel that yielded this D value (step 
621) . This process is repeated for all low frequency 
pixels and CCT 513 is updated accordingly. 

Turning to FIG. 7, RGB NRDT step 519 (FIG. 5A) is 
illustrated in further detail. This process operates on 

10 every block of pixels. Current pixel block 700 represents 
a block of pixels of the video image contained in the 
current frame buffer (i.e., frame buffer 0 503 or frame 
buffer 1 505 (FIG. 5A) ) . Previous pixel block 701 contains 
the corresponding block of pixels of the video image 

15 contained in compare frame buffer 521 (FIG. 5A) . Step 519 
begins by extracting corresponding pixel values for one 
pixel from the current pixel block 700 and previous pixel 
block 701 (step 703) . Then, the pixel color values are 
used to calculate a distance value, which indicates the 

20 magnitude of the similarity or difference between the 
colors of the two pixels (step 705) . In the preferred 
embodiment of the present invention, the distance value is 
computed using the following formula: 

D = (R, - R/ + (G, - G/ + (B, - B/ 
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As before, Rl, Gl, and Bl are the red, green and blue 
values respectively of the frame buffer pixel. Similarly, 
R2, G2, and B2 are the red, green and blue values 
respectively for the compare frame buffer pixel. 
5 Next, the computed distance value D is compared with a 

pixel threshold (step 7 07) . If D is greater than the pixel 
threshold, it is added to an accumulating distance sum 
(step 709) . If the value of D is less than the pixel 
threshold, the difference is considered to be insignificant 

10 (i.e., noise) and it is not added to the distance sum. 

This process of computing distance values and summing 
distance values that are greater than a predefined pixel 
threshold continues until it is determined that the last 
pixel of the block of pixels has been processed (step 711) . 

15 Once the last pixel is reached, the distance sum is 

compared with a second threshold, the block threshold (step 
713) . If the distance sum is greater than the block 
threshold, the current block of pixels designated as 
changed as compared to the corresponding block of pixels 

20 from the previously captured frame. Otherwise, if the 

distance sum is less than the block threshold, the block of 
pixels is designated as unchanged. 

If the block of pixels is designated as changed, step 
715 is executed. Step 715 sets a flag that indicates that 
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the particular block of pixels has changed. Furthermore, 
the new block of pixels is written to compare frame buffer 
521 (FIG. 5A) to replace the corresponding previous block 
of pixels. 

5 Otherwise, if the distance sum does not exceed the 

block threshold, the block is designated unchanged and, a 
flag is set to indicate that this block of pixels does not 
need to be re-transmitted to the remote participation 
equipment (step 721) . Rather, the remote participation 

10 equipment will recreate the portion of the video image 

represented by the block of pixels using the same block of 
pixels displayed for the previous frame of video. At this 
point the system computers CRCs for changed blocks of 
pixels (step 523 of FIG. 5A) as discussed in greater detail 

15 above with respect to FIG. 5A. 

FIG. 8 further illustrates the two level thresholding 
used by the NRDT sub-algorithm shown in FIG. 7. For 
illustrative purposes only, 4x4 blocks of pixels are shown. 
Each pixel is given red, green, and blue color values that 

20 range from 0 to 255, as is commonly performed in the art. 
A pixel having red, green, and blue values of 0 represents 
a black pixel, whereas a pixel having red, green, and blue 
values of 255 represents a white pixel. Previous pixel 
block 751 is a block of pixels grabbed from compare frame 
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buffer 521 (FIG. 5A) . Previous pixel 1 752 is the pixel in 
the upper, left corner of previous pixel block 751. Since 
every pixel of previous pixel block 751 has a value of 0, 
previous pixel block 751 represents a 4x4 pixel area that 
5 is completely black. 

Current pixel block 753 represents the same spatial 
area of the video frame as previous pixel block 751, but it 
is one frame later. Here current pixel 1 754 is the same 
pixel 1 as previous pixel 1 752, but is one frame later. 

10 For simplicity, suppose a small white object, such as a 
white cursor, enters the area of the video image 
represented by previous pixel block 751. This change 
occurs in current pixel 1 754 of current pixel block 753. 
In current pixel block 753, the majority of the pixels 

15 remained black, but current pixel 1 754 is now white, as 
represented by the RGB color values of 255, 255, and 255. 

Further suppose that noise has been introduced by the 
A/D conversion, such that previous pixel 755 has changed 
from black, as represented by its RGB values of 0, 0, and 

20 0, to gray. The new gray color is represented by the RGB 
values of 2, 2, and 2 assigned to current pixel 756. 

Further suppose that the pixel threshold is 100, and 
the block threshold is 200. The NRDT sub-algorithm 
calculates the distance value between each pixel of current 
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pixel block 753 and previous pixel block 751. The formula 
used in the preferred embodiment of the present invention, 
as discussed above with respect to FIG. 7, is: 

D = (R, - R^)' + {G, - G^)' + (B, - B^)' 
Therefore, the distance value between current pixel 1 754 
and previous pixel 1 752 is: 

D = (255 - 0)' 4- (255 - 0)' + (255 - 0)' 
or 195,075. This distance value is added to the distance 
sum because 195,075 exceeds the pixel threshold of 100, 
However, the distance value between the black previous 
pixel 755 and the gray current pixel 756 is not added to 
the distance sum because the distance between the pixels, 
as calculated using the above distance formula, equals 12, 
which does not exceed the pixel threshold of 100. 
Similarly, the distance value is computed for all of the 
remaining pixels in the two pixel blocks . Each of these 
distance values equals zero, therefore, since these 
distance values are less than the pixel threshold, they are 
not added to the distance sum. 

Consequently, after the distance values for all pixels 
have been processed, the distance sum equals 195,075. 
Since this value is greater than the block threshold of 
200, the block is designated. This example illustrates the 
advantages of the two- level thresholding feature of the 



NRDT sub-algorithm. That is, the noise that occurred in 
current pixel 756 of current pixel block 753 was ignored, 
whereas the real change in video that occurred in current 
pixel 1 754 of current pixel block 753 was recognized. 
5 Turning finally to FIG. 9, shown is a flowchart of the 

decompression algorithm executed by user workstation 101 
(FIG. 1) . The decompression algorithm begins by waiting 
for a message (step 801) . This message is transmitted from 
server stack 417 of RMU 109 to user workstation 101. 

10 Thereafter, user workstation 101 receives the information 
and writes the data to client stack 803. Client stack 803 
may be a register or some other device capable of 
permanently or temporarily storing digital data. In one 
embodiment of the present invention, messages are 

15 transmitted using the TCP/IP communication protocol. In 

this scenario, client stack 803 is the local TCP/IP stack. 
Other embodiments may use a protocol other than TCP/IP. 
However, irrespective of the communication protocol, the 
present invention uses client stack 803 to store received 

20 messages for processing. 

Once a message is received in client stack 803, it is 
processed to determine whether the message is a new video 
mode message (step 805) . A new video mode message may be 
sent for a variety of reasons including a bandwidth change, 
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a change in screen resolution or color depth, a new client, 
etc. This list is not intended to limit the reasons for 
sending a new video mode message, but instead to give 
examples of when it may occur. If the message is a new 
5 video mode message, application layer 823 is notified of 
the new video mode (step 807) . According to the preferred 
embodiment, application layer 823 is software executed by 
user workstation 101 that interfaces with the input and 
output devices of user workstation 101 (i.e., keyboard 103, 

10 video monitor 105, and cursor control device 107) . Any 
video updates must therefore be sent to application layer 
823. Also, the old buffers are freed, including all memory 
devoted to storing previously transmitted frames, and new 
buffers are allocated (step 809) . The decompression 

15 algorithm then returns to step 801. 

If the new message is not a video mode message, the 
message is further processed to determine if it is a cache 
hit message (step 811) . If yes, the cache hit message is 
deciphered to determine which block of pixels, of the 

20 blocks of pixels stored in the three cache frame buffers 
815, should be used to reconstruct the respective portion 
of the video image. Although three cache frame buffers 815 
are used in the preferred embodiment of the present 
invention, any quantity of cache frame buffers may be used 
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without departing from the spirit of the invention. Cache 
frame buffers 815 store the same blocks of pixels that are 
stored in the cache frame buffers located internal to RMU 
109 (FIG. 3) . Thus, the cache hit message does not include 
5 video data, but rather simply directs the remote 

participation equipment as to which block of pixels 
contained in the cache frame buffer 815 should be sent to 
merge frame buffer 817. The block of pixels contained 
within the specified cache is then copied from cache frame 

10 buffer 815 to merge buffer 817 (step 813) . Finally, 

application layer 823 is notified that an area of the video 
image has been updated (step 825) . Merge buffer 817 
contains the current representation of the entire frame of 
video in color code pixels. Application layer 823 copies 

15 the pixel data from merge buffer 817 and formats the data 
to match the pixel format of the connected video monitor 
105 (step 819) . Thereafter, the formatted pixel data is 
written to update frame buffer 821, which then transmits 
the data to video monitor 105. Alternatively, in lieu of a 

20 video monitor, the formatted pixel data may be written to a 
video card, memory, and/or any other hardware or software 
commonly used with video display devices. 

Further, if the new message is not a new video mode or 
cache hit message, it is tested to determine if it is a 
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message containing compressed video data (step 827) . If 
the message does not contain compressed video data, the 
decompression algorithm returns to step 801 and waits for a 
new message to be transmitted from server stack 417. 
5 Otherwise, if the message does contain compressed video 

data, the data is decompressed and transferred to bit plane 
frame buffer 833 (step 829) . As described above, the 
preferred embodiment incorporates the JBIG lossless 
compression technique. Therefore, decompression of the 

10 video data must be performed for each individual bit plane. 
After each bit plane is decompressed, it is merged with 
previously decompressed bit planes, which are stored in bit 
plane frame buffer 833 (step 829) . When a sufficient 
number of bit planes have been merged, the merged data 

15 contained in bit plane frame buffer 833 is transferred to 
merge frame buffer 817 (step 831) . Alternatively, 
individual bit planes may be decompressed and stored 
directly in merge frame buffer 817, thereby eliminating 
step 831. When all of the data required to display a full 

20 frame of video is transferred to merge frame buffer 817, 

application layer 823 copies the data in merge frame buffer 
817 to update frame buffer 821 (step 819) . Thereafter, the 
data is transferred to video monitor 105. 
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In an alternate embodiment, the video displayed on 
video monitor 105 can be updated after each bit plane is 
received. In other words, a user does not have to wait 
until the whole updated frame of video is received to 
5 update portions of the displayed video. This alternative 
method is desirable when the bandwidth available for video 
transmission varies. Also, this progressive method of 
updating the video display is one of the advantages of 
using the JBIG compression algorithm. 

10 Next, the decompression algorithm determines whether 

all of the color code data from one field of the current 
video frame has been received (step 835) . If a full field 
has not been received, the decompression algorithm returns 
to step 801 and waits for the remainder of the message, 

15 which is transmitted from server stack 417 to client stack 
803 in the form of a new message. Otherwise, if a full 
field has been received, the decompression method notifies 
application layer 823 (step 837) . Similar to that 
described above with respect to processing cache hit 

20 messages, this notification directs application layer 823 
to read the data in merge frame buffer 817 and convert it 
to the current screen pixel format (step 819) . Thereafter, 
the formatted data is written to update frame buffer 821, 
which transmits the data to video monitor 105. 
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After a full field has been received and application 
layer 823 has been notified, a second determination is made 
to determine if the full field is the last field included 
in the message. If it is, the newly decompressed block of 
5 pixels is written to one of the cache frame buffers 815 

(step 841) . Otherwise, the decompression algorithm returns 
to step 801 and continues to wait for a new message. 
Preferably, the new block of pixels written to cache frame 
buffer 815 overwrites the oldest block of pixels contained 

10 therein. Step 841 ensures that the cache is up-to-date and 
synchronized with the cache of RMU 109. After the 
completion of the cache update, the decompression algorithm 
returns to step 801. 

While the present invention has been described with 

15 reference to the preferred embodiments and several 

alternative embodiments, which embodiments have been set 
forth in considerable detail for the purposes of making a 
complete disclosure of the invention, such embodiments are 
merely exemplary and are not intended to be limiting or 

20 represent an exhaustive enumeration of all aspects of the 

invention. The scope of the invention, therefore, shall be 
defined solely by the following claims. Further, it will 
be apparent to those of skill in the art that numerous 
changes may be made in such details without departing from 
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the spirit and the principles of the invention. It should 
be appreciated that the present invention is capable of 
being embodied in other forms without departing from its 
essential characteristics . 



-80- 



